-
Notifications
You must be signed in to change notification settings - Fork 10k
adding-instance-restarts-changelog-entry #26372
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: production
Are you sure you want to change the base?
adding-instance-restarts-changelog-entry #26372
Conversation
| @@ -0,0 +1,21 @@ | |||
| --- | |||
| title: Instance restarts now supported in Workflows | |||
| description: You can now restart an instance of your workflow without losing its concurrency spot | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
capitalize Workflow?
| await instance.restart(); // Returns Promise<void> | ||
| ``` | ||
|
|
||
| You may want to [restart an instance](/workflows/build/trigger-workflows/#restart-a-workflow) if the Workflow has been updated, the parameters have changed, or the Workflow has reached its step limit. Restarting an instance will immediately cancel any in-progress steps, erase any intermediate state, and treat the Workflow as if it was run for the first time. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be good to add a sentence here of why this is important
|
|
||
| You may want to [restart an instance](/workflows/build/trigger-workflows/#restart-a-workflow) if the Workflow has been updated, the parameters have changed, or the Workflow has reached its step limit. Restarting an instance will immediately cancel any in-progress steps, erase any intermediate state, and treat the Workflow as if it was run for the first time. | ||
|
|
||
| If the instance is already running, the restart will not lose its concurrency slot (limit of 10,000 concurrent instances). However, the restarted instance will count towards the creation rate limit (100 instances per second). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is a bit confusing to parse. i would clarify concurrency vs. creation here a bit more. i.e. does this help if i have 10,001 instances? or is this useful in general?
what does creation mean here?
|
|
||
| If the instance is already running, the restart will not lose its concurrency slot (limit of 10,000 concurrent instances). For example, say you have 10,000 instances running and 2,000 instances queued. If you restart a runnning instance, it will maintain its spot in the 10,000 rather than slotting into the back of the queue. | ||
|
|
||
| However, note that the restarted instance will count towards the instance creation rate limit (100 Workflow instances per second). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would drop this line. I think it adds more questions than it answers (assuming this is documented)
|
|
||
| You may want to [restart an instance](/workflows/build/trigger-workflows/#restart-a-workflow) if the Workflow has been updated, the parameters have changed, or the Workflow has reached its step limit. This allows you to make changes without waiting until the instance is complete or preserve a long-running instance through restart. Restarting an instance will immediately cancel any in-progress steps, erase any intermediate state, and treat the Workflow as if it was run for the first time. | ||
|
|
||
| If the instance is already running, the restart will not lose its concurrency slot (limit of 10,000 concurrent instances). For example, say you have 10,000 instances running and 2,000 instances queued. If you restart a runnning instance, it will maintain its spot in the 10,000 rather than slotting into the back of the queue. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the example. You can be more concrete — and say if the instance was in the 300th slot, it would go back in there as opposed to the 2001st.
Summary
Adding changelog for instance.restart() support in Cloudflare Workflows